Add built-in package management REST API#6247
Add built-in package management REST API#6247joewiz wants to merge 1 commit intoeXist-db:developfrom
Conversation
|
May I suggest that this should go into its own separate module. The exist-core module was created with the specific purpose of being slimmed down rather than made bigger, the previous plans was to remove everything from exist-core apart from core database engine. |
…module Add PackageManagementServlet, PackageService, and RepoPackageLoader in a new exist-services Maven module (not exist-core) per the architectural principle that exist-core should contain only the core database engine. The exist-services module provides built-in HTTP services for the eXist-db platform: package CRUD at /api/packages — list, get, install (registry + upload), remove (with dependency checking), update-check, icon serving. Compiled into the platform, no XAR dependency. Solves the self-upgrade problem that existdb-packageservice had. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
6982d52 to
4716cfa
Compare
PR eXist-db#6247: Add built-in package management REST API. Will be extracted to exist-services module per reviewer feedback.
…ces module Per reviewer feedback on PRs eXist-db#6247 and eXist-db#6248, move PackageManagementServlet, PackageService, RepoPackageLoader, OpenApiServlet, OpenApiServiceRegistry, OpenApiStartupTrigger, and OpenApiTrigger from exist-core into a new exist-services Maven module. exist-core was designed to contain only the core database engine. These HTTP services (package management REST API and OpenAPI routing) are platform capabilities that depend on exist-core but aren't part of the database engine. The classes keep their original packages (org.exist.http.servlets, org.exist.http.openapi, org.exist.repo) — only the Maven module changes. exist-services is included in the distribution via exist-distribution's dependency list and gets shaded into the uber JAR. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@joewiz I am intrigued by the approach you chose here. I assume that this does integrate with your other proposals to extend and unify the REST API exposed by exist-db. I do see testfailures. Since xst is not using the packagemanager/exist-packageservice at all it can be removed from the testplan. |
Summary
Add a built-in package management REST API to eXist-db, eliminating the need for the
existdb-packageserviceXAR package. The servlet handles package CRUD operations — list, get, install (from registry or upload), remove (with dependency checking), update-check, and icon serving.What Changed
All new code is in the
exist-servicesMaven module (notexist-core), per the architectural principle that exist-core should contain only the core database engine.New module:
exist-services/PackageManagementServlet.java— HTTP servlet at/api/packagesfor package CRUDPackageService.java— business logic for package operations (install, remove, dependency resolution)RepoPackageLoader.java— downloads packages from public/private registriesConfiguration
web.xml— servlet registration with multipart config for XAR uploadscontroller-config.xml— URL pattern forwarding for/api/packagespom.xml— newexist-servicesmodule in reactor andexist-distributiondependencyMotivation
The
existdb-packageserviceXAR package has a fundamental problem: it can't upgrade itself. The XQuery code executing the upgrade gets deleted mid-operation when the package is removed. By moving package management into the platform (compiled Java), this self-upgrade problem is eliminated.Test Plan
mvn install -pl exist-services -am -DskipTestscompiles cleanlypackages.cy.js)xst package install/remove/listworks against the built-in API🤖 Generated with Claude Code